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(57) Abstract: A method of electronic payment for data 
transferred across a computer network from a server (26) 
to a client (20) by means of at least one router (22, 24) 
which forwards data. An electronic data request is sent 
from the client to the server via one or more routers. The 
server (26) then sends electronic data (8) to the client (20) 
via one or more routers in response to said electronic data 
request The electronic data is sent via a packet transfer 
protocol in which each packet of data (10) has associated 
with it a data field (5) containing a value which represents 
the commercial value of the requested data (8). Each router 
(22, 24) receives an incoming data packet (10), reads the 
value in the data field (5) associated with the incoming data 
packet, calculates a new value based on the read value and 
the cost of forwarding the data packet, and forwards the data 
packet (10) with the new value in the associated data field 
(5). Each router can check whether the value in the data field 
(5) associated with the incoming data packet rails within 
predefined "parameters". 
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1 Computer network payment system 

2 

3 The invention relates to a system and method for 

4 transferring payments corresponding to the supply of 

5 information over a computer network. In particular the 

6 invention relates to a system and method for 

7 transmitting payment information between servers and 

8 clients by means of a hardware infrastructure of linked 

9 routers and by means of a specially adapted protocol . 

10 The protocol used by the system and method of the 

11 invention is referred to herein as "Packet Tariff 

12 Protocol" or *PTP" . It is to be understood that the 

13 term PTP when used in the following description should 

14 be taken to mean a protocol adapted for use with 

15 systems which transfer data in packets between servers 

16 and clients, the protocol enabling the transmittal of 

17 payment information between the servers and clients. 
18 

19 It is also be to understood that the term "packet" when 

20 used in the following description should be taken to be 



WO00y79494 



2 



PCT/GBO0/D2413 



1 a generic term, meaning any discrete package or block 

2 of data that is described by any particular protocol, 

3 as appropriate to any particular communication layer. 

4 For the purposes of the following description the term 

5 "packet" should therefore include message, segment, 

6 datagram, frame and any other term which by definition 

7 or common usage is accepted as meaning a discrete 

8 package or block of data in the context of a specific 

9 protocol, as appropriate to any particular 
10 communication layer. 

11 

12 Access to the Internet is freely available everywhere 

13 and the advent of e-commerce, or electronic trading, is 

14 set to revolutionize the way that business is done. 

15 However there remains a requirement for effective 

16 trading of information itself. As the infrastructure 

17 and available bandwidth expand. to appropriate levels, 

18 the world will become a single, on-line, global, 

19 multimedia library. All public domain information will 

20 be available to anyone with a network connection, via a 

21 simple, easy to use interface, analogous to today's 

22 Web browser application. In addition, suitable tools 

23 will be developed to manage the information and tailor 

24 all that is available to suit the particular needs of 

25 each individual. There are two major consequences of 

26 this, as follows. 
27 

28 Firstly, holding information locally will become 

29 redundant. This means that books, CDs, prerecorded 

30 videotapes and so on will eventually not be required. 

31 When information is sufficiently cheap and reaches the 

32 necessary levels of specificity and availability, there 
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1 will be no point in individuals holding local copies of 

2 the information, in the form of books, CDs, tapes etc., 

3 that will quickly go out of date. They will simply 

4 access the* latest, updated information from its 

5 original source or retrieve other data (noting that any 

6 digital multimedia information is fundamentally just 

7 data) from on-line archives. 
8 

9 Secondly, broadcast media will also become redundant. 

10 Radio stations, TV channels, newspapers and journals 

11 will no longer serve any purpose. Once again, highly 

12 sophisticated information management tools will 

13 retrieve information from the massive range of 

14 disparate original sources that will come into 

15 existence, with the output collated, rationalized and 

16 customized to match the particular requirements of each 

17 networked individual. 
18 

19 These changes lie in the future, but are inevitable, 

20 and are likely to result in commercial upheaval and 

21 colossal social changes. At present, however, there 

22 remains a pressing need for a consistent and 

23 appropriate system or method to permit the 

24 implementation of this trade in information. The 

25 system must conform to, and operate under, the 

26 conditions that exist within free-market commercial and 

27 national economies. It is the development of a 

28 proposed solution to this problem which is addressed by 

29 the present invention. 
30 

31 The PTP or "Packet Tariff Protocol" is an element 

32 within an effective system for digital networks at 
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1 packet level. The protocol is envisaged as, but not 

2 limited to, an evolution of the existing TCP/IP 

3 (Transmission Control Protocol/Internet Protocol) 

4 standard that forms the core of the Internet as it 

5 presently exists. However PTP is not limited to TCP/IP 

6 applications, but can be used in any environment where 

7 there is transfer of data in distinct pieces or 

8 packets, for example WAP (Wireless Application 

9 Protocol) , UMTS (Universal Mobile Telecommunications 

10 System), GPRS (General Packet Radio Service) or others. 
11 

12 According to a first aspect of the present invention 

13 there is provided a method of electronic payment for 

14 data transferred across a computer network containing 

15 at least one client, at least one server and at least 

16 one router which forwards data, the method comprising 

17 the steps of: 

18 sending an electronic data request from a client 

19 to a server via one or more routers; and 

20 sending electronic data from said server to said 

21 client via one or more routers in response to said 

22 electronic data request, said electronic data having 

23 associated with it a data field containing a value 

24 which represents the commercial value of the data 

25 contained within the electronic data. 
26 

27 Preferably the electronic data is transmitted in the 

28 form of packets. Preferably each of said one or more 

29 routers receives an incoming data packet, reads the 

30 value in the data field associated with the incoming 

31 data packet, calculates a new value based on the read 

32 value and the cost of forwarding the data packet, and 



WO 00/794SM 



5 



PCT/GBOO/02413 



1 forwards the data packet with the new value in the 

2 associated data field. 
3 

4 Preferably each of said one or more routers- checks 

5 whether the value in the data field associated with the 

6 incoming data packet falls within predefined parameters 

7 and rejects the packet if the value falls outside the 

8 predefined parameters. The parameters may depend on 

9 the source of the data packet or the originator of the 
10 data request. 

11 

12 The electronic data request may also have associated 

13 with it a data field containing a value which 

14 represents the commercial value of the data contained 

15 within the electronic data request. 
16 

17 Preferably total accumulated values for transactions 

18 between routers or between routers and servers/clients 

19 are recorded. These total values may be used as the 

20 basis for payments between the operators and/or users 

21 of the routers, servers or clients. Periodic clearance 

22 payments may be made between the operators and/or users 

23 of the routers, servers or clients, the clearance 

24 payments corresponding to the total accumulated values. 
25 

26 According to a second aspect of the present invention 

27 there is provided a system of electronic payment for 

28 data based on a hardware infrastructure of linked 

29 routers, data providers and data users, comprising: 
3 0 at least one client; 

31 at least one server for providing electronic data 

32 in the form of data packets in response to a request 
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1 from a client and having its operation governed by a 

2 server protocol which causes each data packet sent by 

3 the server to have associated with it a data field 

4 representing the value of the data contained within the 

5 packet; 

6 at least one router linked by a hardware 

7 infrastructure to said server and said client and 

8 having its operation governed by a routing table and a 

9 router protocol; 

10 whereby the router protocol causes each router to 

11 add commercial value to the packet by forwarding it in 

12 accordance with the routing table and to update the 

13 value contained in the data field within the packet to 

14 reflect this added commercial value. 
15 

16 Preferably the router protocol also includes procedures 

17 for rejecting individual packets in accordance with 

18 pre-defined parameters related to the value of each 

19 packet on receipt . 
20 

21 According to a third aspect of the invention there is 

22 provided a method of electronic payment for data 

23 transferred across a computer network containing at 

24 least one client, at least one server and at least one 

25 part of the network which forwards data, the method 

26 comprising the steps of : 

27 sending an electronic data request from a client 

28 to a server via the part of the network; and 

29 sending electronic data from said server to said 

30 client via the part of the network in response to said 

31 electronic data request, said electronic data having 

32 associated with it a data field containing a value 
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1 which represents the commercial value of the data 

2 contained within the electronic data. 
3 

4 Preferably the electronic data is transmitted in the 

5 form of packets. Preferably the part of the network 

6 has an associated data processor which reads the value 

7 in the data field associated with an incoming data 

8 packet received by the part of the network, calculates 

9 a new value based on the read value and the cost of 

10 forwarding the data packet, and forwards the data 

11 packet with the new value in the associated data field. 
12 

13 The data processor may check whether the value in the 

14 data field associated with the incoming data packet 

15 falls within predefined parameters and rejects the 

16 packet if the value falls outside the predefined 

17 parameters . 
18 

19 According to a fourth aspect of the invention there is 

20 provided a method of electronic payment for requested 

21 data transferred across a computer network containing 

22 at least one client, at least one server and at least 

23 one router which forwards data, in which the requested 

24 data is sent from said server to said client in the 

25 form of a packet, 

26 wherein said packet comprises a packet header and 

27 packet data, 

28 the packet data containing the requested data, and 

29 the packet header containing one or more address 

30 fields containing address information relating to the 

31 client and/or server and a data field containing a 
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1 value which represents the commercial value of the 

2 requested data contained within the packet data. 
3 

4 Preferably the data is sent via the router which reads 

5 the value in the data field of the incoming data packet 

6 received by the router, calculates a new value based on 

7 the read value and the cost of forwarding the data 

8 packet, writes the new value to the data field, and 

9 forwards the data packet with the new value in the data 
10 field. 

11 

12 The invention will now be described, by way of example 

13 only, with reference to the accompanying figures, 

14 where : 
15 

16 Fig. 1 is a schematic representation of a typical 

17 generic form of a digital data packet under the system 

18 of the invention; 
19 

20 Fig. 2 is a schematic representation of a fragment of a 

21 ne t work ; and 
22 

23 Fig. 3 is a flow chart showing the operation of a 

24 network router under the system according to the 

25 invention. 
26 

27 The invention can best be understood by considering the 

28 metaphor of the supply chain with associated added 

29 value at each stage. In other words, at each step in 

30 the process to supply the information, value is added 

31 over and above the intrinsic value of the information. 

32 Therefore, an additional cost is associated with the 
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1 information at each stage, until it reaches its 

2 ultimate destination. In practice, this is achieved by 

3 the incorporation of a "value" field into each data 

4 packet, allied with network protocol extensions to 

5 implement and utilize this field in the packet. This 

6 is applied in a way that ultimately results in the cost 

7 of providing the intrinsic information and the cost of 

8 providing the transport service being enumerated and 

9 accrued in the value field. These costs are thus 

10 accounted for within the same system that actually 

11 provides the data transport service, so that the supply 

12 chain and the value chain are both incorporated into 

13 the network protocols. 
14 

15 The value field may be augmented with a "priority" 

16 field, along the lines that have already been proposed 

17 by other bodies as part of existing technical 

18 specifications. Within this framework though, the 

19 priority field can additionally be used as part of the 

20 commercial system if required, so that different 

21 services can incur different costs although they may 

22 share the same hardware and network infrastructure. In 

23 some prior art developments, the "priority" field of a 

24 data packet has evolved to serve a more advanced 

25 purpose, and the field contains a code that indicates 

26 how data should be handled, according to its 

27 characteristics. For example, transmission of data 

28 that is part of a video stream might not be re-tried if 

29 it fails first time, since a degraded video output is 

30 considered to be more useful to the ultimate end-user 

31 than a pause to wait for all the information to achieve 

32 perfect reproduction. In contrast, a file transfer can 
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1 usually wait for the availability of network capacity, 

2 but must ultimately be one hundred percent complete, 

3 accurate and checked if it is to be of practical use. 
4 

5 In the system according to the invention, data is 

6 transferred between servers and clients in packets. 

7 Fig. 1 shows the typical generic form of a digital data 

8 packet under the implementation of PTP. 
9 

10 The packet 10 is simply data in a mutually understood 

11 format. In the example of Fig. 1, it is divided into 

12 three sections 1, 2, 3. Each section may be further 

13 divided into multiple fields, as described below. The 

14 packet header 1 contains general fields 4 for 

15 addressing information or other information and also 

16 contains a value field 5. The number of general fields 

17 4 depends on the protocol used, and it is to be 

18 understood that the number of general fields 4 and the 

19 position of the value field 5 within the packet header 

20 1 may vary. The packet data 2 contains the data 8 and 

21 follows the packet header 1. The packet tail 3 follows 

22 the packet data 2 and is optional, but would typically 

23 contain a field 6 containing the checksum for the 

24 packet, or similar error detection information, and may 

25 contain other general fields 7. Again it is to be 

26 understood that the number of general fields 7 and the 

27 position of the checksum field 6 within the packet tail 

28 3 may vary. It is to be understood that the value 

29 field may be in any position within the packet, for 

30 example within the payload or packet data 2, or within 

31 the packet tail 3. 
32 
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1 Each data packet 10 includes a value field 5, which 

2 contains information about the intrinsic value of the 

3 data 8 contained within the packet, and which 

4 accumulates the charges made for each step in the 

5 provision of the service for supplying that data packet 

6 to its ultimate recipient. As an example, this 

7 aggregated overall worth may be measured in Network 

8 Credit Units (NCU's). 
9 

10 For the purpose of applying tariffs, the network system 

11 is considered to consist of "servers", "routers" and 

12 "clients" although in practice a single machine or even 

13 a single software application may fulfil more than one 

14 of these functions at different times. For example, a 

15 router can be considered to be acting as a client to 

16 many servers and as a server to many clients, as 

17 defined by the routing tables to which it adheres at 

18 any particular moment in time. 
19 

20 Fig. 2 is a diagram showing a network fragment. Under 

21 the system of the invention it may operate in the 

22 following manner. The web client 20 operated by the 

23 ultimate end user requests information in the form of a 

24 message that passes through router (N) 22 at the 

25 internet service provider (ISP) connection and accrues 

26 added value as a result of the action of the transport 

27 service. The message subsequently passes through a 

28 number of intermediate routers (not shown) and finally 

29 through router (A) 24 and accrues more added value for 
3 0 the extra transport service. The intermediate routers 

31 and routers (A) and (N) form the network infrastructure 

32 carrying the data. The message then arrives at the web 



WO 00)79494 PCT/GBOO/02413 

12 



1 server 26, which responds by initiating a data stream. 

2 The web server 26 is operated by a content provider. 

3 The packets of this data stream typically have 

4 intrinsic value, associated with the information that 

5 they contain, the information being provided or sold by 

6 the content provider. The appropriate component of 

7 this intrinsic value is recorded in each packet . The 

8 packets then pass back via router (A) 24 and have the 

9 associated value of the transport service added to 

10 them. Similarly, router (N) 22 passes the data stream 

11 and adds further value to the packets for the service 

12 provided. The information finally arrives at the web 

13 client 20, as required. 
14 

15 For each machine on the network, the net values of 

16 packets received and transmitted via each hardware 

17 connection can then be calculated. These values are 

18 reconciled by the owners of all the machines involved, 

19 as the basis for assessing the economic value of the 

20 services provided and calculating the commensurate hard 

21 currency exchanges required. This process is described 

22 in more detail below. 
23 

24 In accordance with the PTP idea, the web client 20, or 

25 any software application functioning as a client, 

26 maintains the right to reject individual packets if 

27 they are deemed w too expensive" by some criteria, 

28 without assuming their associated notional cost. 

29 Additional control is maintained by monitoring the 

30 value of incoming packets in real time, typically by 

31 summing the total value arriving in the last second 

32 and/or minute and/or hour and/or other time interval, 
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1 as required. This might, for example, be depicted by a 

2 meter representation or bar indicator on a network 

3 terminal screen. Over a short time period, of the 

4 order of a few seconds or so, it might be acceptable to 

5 have a large amount of data arriving with a large value 

6 at a high rate of value accrual, for example when 

7 downloading a software application. However over a 

8 longer time period, of the order of an hour or so, a 

9 high rate of value accrual might be unacceptable while 

10 it might be acceptable to have a continuous stream of 

11 data arriving with a smaller value, for example when 

12 downloading a movie or video in real time . A meter 

13 representation could also apply to an Internet 

14 telephone, and the system could show the cost of a call 

15 as it takes place, rather than the owner subscribing to 

16 the service on a predetermined tariff scheme. This 

17 does not preclude a service provider agreeing to absorb 

18 the fluctuations in cost and passing on packets at 

19 agreed rates if such a service is desired by clients on 

20 the network. This might be appropriate, for example, 

21 if a client actually desired predetermined costs for 

22 use of the system, e.g. for budgeting purposes. 
23 

24 The invention is now described in more detail. For the 

25 purposes of the description herein, a packet originates 

26 from a server that acts as a "content provider", i.e. 

27 it is the source of the data or information contained 

28 within the packet that is to be transferred. This 

29 piece of information and the service of providing it 

30 both have some inherent worth and this worth can be 

31 enumerated and written in the value field of the 

32 packet. This is the first element of the system of the 
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1 present invention, in that content providers can attach 

2 a value to the information that they provide and, 

3 further, they can assert the claim to that value along 

4 the same delivery channel as that by which the 

5 information itself is supplied. On receipt of the 

6 packet, the client (or router acting as a client) can 

7 accept the packet or reject it. The control system 

8 which makes the decision and determines the outcome of 

9 this choice is described later. It is of importance, 

10 because information cannot meaningfully be returned 

11 once received. 
12 

13 Assuming that a router receives and accepts a packet, 

14 it then acts in its role as a server and forwards it in 

15 accordance with the routing tables it currently holds. 

16 It should be noted that this always entails sending the 

17 packet down a physical data connection of some sort. 

18 The network is defined by the routing tables, but 

19 always has a physical existence as data conduits 

20 between machines. In the system of the invention, the 

21 routing machine defines the worth associated with the 

22 action of passing a packet from one machine to the 

23 next. It might be a fixed rate, or it might be 

24 dependent on the priority of the packet or on some 

25 other parameters (e.g. network loading, time of day, 

26 physical distance between machines, available 

27 bandwidth, ownership of network infrastructure, etc.). 

28 The important point is that this evaluation can be 

29 resolved by the router (probably as part of its routing 

30 software) as it passes the packet and that the outcome 

31 of this calculation is added to the value field of the 

32 packet in transition (i.e., before it is forwarded). 
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1 This is the second element of the system of the present 

2 invention, in that network infrastructure providers can 

3 attach a value to the service of transporting 

4 information and, further, they can assert the claim to 

5 that value along the same delivery channel as that by 

6 which the information itself is supplied. It is also 

7 necessary for each machine to accumulate the total 

8 number of NCU' s it receives from each physical 

9 connection and the total number of NCU' s it dispatches 

10 to each physical connection, excluding those attributed 

11 to packets that are subsequently rejected. It should 

12 also be noted that physical connections for the receipt 

13 of packets are considered to be distinct from physical 

14 connections for the dispatch of packets, even though 

15 they might be manifested in the same piece of cabling. 
16 

17 Under these conditions, the number of NCU's transmitted 

18 from the machine at one end of a physical connection 

19 should agree with the number of NCU's accepted by the 

20 machine at the other end. These machines may be owned 

21 by different organizations but, on the basis that they 

22 agreed to make the trades, they should be reasonably 

23 expected to have mutual interest in ensuring accuracy 

24 in accounting. A commercial analogy for this would be 

25 a deal done on an w open outcry" trading floor, in which 

26 two parties agree a deal by signals and each makes a 

27 record of it independently. The independent records 

28 are reconciled at a later stage but, since both parties 

29 agreed the initial deal, both are assumed to have an 

30 interest in making sure that it is recorded accurately. 

31 The analogy goes further, since any party that 

32 establishes a reputation for not recording deals 
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1 accurately will simply find it impossible to establish 

2 or maintain any profitable trades. 
3 

4 Within this protocol, any recipient reserves the right 

5 to reject any packet. This rejection includes refusal 

6 to accept the debt associated with' receipt of the 

7 packet. The most probable reason for this is that the 

8 packet is deemed by some criteria to be "too 

9 expensive". This act of rejection is an important part 

10 of the protocol and therefore warrants detailed 

11 discussion. As discussed above, once data is received 

12 it cannot be meaningfully returned, since it is not a 

13 physical object. On first inspection, then, it seems 

14 that there would be a propensity to defraud suppliers 

15 by rejecting packets (and therefore the liability to 

16 pay for them) whilst still forwarding the data and 

17 charging for it. However, the post-receipt rejection 

18 process is vital to remove completely the possibility 

19 that single "rogue" packets of massive value are 

20 foisted on unsuspecting recipients. The reason that an 

21 immediate breakdown of the system according to the 

22 invention does not follow is because successful trading 

23 requires streams of many packets of modest value to be 

24 passed through the network. In the proposed scenario, 

25 the "catch *em once" price- value combination is 

26 excluded by this ability to refuse to pay for 

27 excessively costly packets. This means that a 

28 sustainable and profitable trade will only occur with 

29 the transmission of an ongoing packet stream. 
30 

31 This "reject" aspect of the system according to the 

32 invention may best be understood by considering a "sale 
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1 or return" analogy. A producer (content provider) 

2 creates a product (data/ information) and delivers it to 

3 a reseller (router) at some cost (the value in NCU's). 

4 The reseller (router) either accepts it, on the basis 

5 that it can be sold on (forwarded to another router or 

6 an end client) at a marked up price (an addition to the 

7 value in NCU's) or, alternatively, rejects it. The 

8 producer (content provider) monitors the rejections of 

9 the reseller (router) and decides on the basis of this 

10 information whether or not to continue trading and, if 

11 so, what price structure to apply. Hence, the choice 

12 of acceptance or rejection of a packet is effectively a 

13 "sale or return" of the data, since keeping occasional 

14 packets without paying for them is of little economic 

15 value. In practice, it will rapidly become the case 

16 that meaningful trade in packet streams allied to 

17 competitive pricing is the only way to maintain 

18 profitable transactions. 
19 

20 Termination criteria are based upon single packet costs 

21 and the cost accumulations of packets over selected 

22 time .intervals. Hence termination requests are issued 

23 if any single packet exceeds the NCU threshold or if 

24 the limits for NCU's per second, minute, hour, day 

25 and/or other time interval are exceeded. The cut-off 

26 levels are best kept confidential to avoid prices being 

27 bumped up to the maximum that would be accepted, 

28 ' although such information could be shared with trusted 

29 counterparts in an attempt to reject packets deemed too 

30 costly at an earlier stage. Note that single-packet 

31 rejection is the only rejection where packets are not 

32 paid for, other termination is simply a request to 
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1 cease supplying data. Data received before supply 

2 terminates are still paid for, subject to single packet 

3 criteria. 
4 

5 Conversely, the value attributed to data by content 

6 providers could be freely advertised. This would make 

7 competition between content providers more effective 

8 and would also highlight expensive transport routes, 

9 since the value of the packet received would have had 

10 risen unacceptably when compared to the initial value 

11 advertised by the content provider. Furthermore, data 

12 network routing should become an extremely efficient 

13 market because data transmission networks can be 

14 reconfigured so easily and pricing structures changed 

15 so readily. This should result in perfect competition, 

16 evolving to satisfy the laws of supply and demand in a 

17 free market. 
18 

19 The final element of the system according to the 

20 invention is achieved by converting the residual 

21 difference in NCU' s exchanged between a pair of 

22 machines over some physical connection into a payment 

23 in mutually acceptable hard currency. This can always 

24 be achieved bilaterally, but could also be administered 

25 by some kind of clearing house with responsibility for 

26 a defined physical region of the network. There is a 

27 potential problem here, unless the exchange value of an 

28 NCU is pegged to some hard currency. Otherwise, it 

29 will float erratically as the number of NCU's per 

30 network transaction can vary inversely with the 

31 exchange rate to hard currency, without changing the 

32 actual monetary worth of the network transaction. The 
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1 problem might however eventually resolve itself if the 

2 NCU becomes a stable, global currency in its own right. 
3 

4 To complete a transaction using this system, an 

5 ultimate client could first issue a request for some 

6 information. For the purpose of this example only, it 

7 will be assumed that this request is contained in a 

8 single packet. The intrinsic value of this packet 

9 would probably be zero but, in all cases, could not 

10 exceed a predetermined maximum accepted by the router 

11 (which may well be the machine of a network service 

12 provider, acting at this point as a client) . Further, 

13 since this machine is probably not owned by the owner 

14 of the ultimate client machine, there would be no 

15 tariff added to the value of the packet. The router, 

16 now acting as a server, adds a tariff to the packet and 

17 passes it to the next router. This process is repeated 

18 across the network until the packet reaches the machine 

19 of the content provider that, somewhat confusingly, is 

20 at this point acting as a client. Hence, the content 

21 provider receives a request for information but becomes 

22 liable for the accrued value of the packet. This value 

23 will be relatively small, since it is only one packet 

24 (or, more generally in practice, a relatively small 

25 number of packets) and it has little or no intrinsic 

26 value in its information content. It can be thought of 

27 as analogous to the cost associated with a free-phone 

28 telephone number that businesses commonly use to 

29 attract enquiries from customers. 
30 

31 The machine of the content provider now acts in its 

32 primary role as a server, and starts to send packets 
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1 addressed to the machine of the ultimate client (i.e. 

2 the machine from which the original request for data 

3 originated) . Since the packets have content that is 

4 deemed to have some worth, these packets now have a 

5 significant value associated with them even as they are 

6 dispatched from the server machine. As they traverse 

7 the network, they will accrue further value until they 

8 reach the ultimate client machine. Routers within the 

9 network will have added value to packets passing both 

10 ways, so that owners of these machines will be in 

11 residual credit after paying for the packets received 

12 and will therefore be able to reclaim hard currency 

13 converted from NCU' s to finance their activities. The 

14 content providers will have some liabilities for the 

15 receipt of the packets requesting data but will have a 

16 large residual credit for supplying the information. 

17 The ultimate client will contribute the majority of the 

18 payments due, which cover the cost of the information 

19 they receive and the cost of the process of 

20 transporting it to them. 
21 

22 The way in which a network router might implement the 

23 PTP, in addition to its existing transport protocol, 

24 for the purposes of transferring data packets and 

25 accumulating the associated tariffs, is illustrated in 

26 the flow chart of Fig. 3. The branches in the flow 

27 chart show possible contingencies at various stages, if 

28 the required conditions are not satisfied. 
29 

30 The router receives 30 a data packet and checks 32 

31 whether the packet is acceptable under the existing 

32 transport protocol. The router also checks 32 whether 



WO 00/79494 PCT/GB00/02413 

21 

1 the routing tables with which it is provided can 

2 resolve the address to yield the hardware connection 

3 along which the packet is to be dispatched. If the 

4 packet is acceptable and the address can be resolved 

5 the router proceeds to step 36. If the packet is not 

6 acceptable or the address cannot be resolved the router 

7 rejects 34 the packet. 
8 

9 The router then checks 36 that the value of the packet 

10 as determined from the value field 5 is below the value 

11 limit acceptable from the incoming hardware connection. 

12 If the value of the packet is not below the value limit 

13 the router rejects 38 the packet under the PTP rules. 

14 If the value of the packet is below the value limit the 

15 router proceeds to the next step, in which the recorded 

16 total value received from this hardware connection is 

17 incremented 40 by the value of the packet. The 

18 recorded total value received is stored by the router. 

20 The router then calculates 42 the value to be added for 

21 the service of transmitting this packet along the 

22 particular hardware connection designated by the 

23 routing tables. This might depend upon the 

24 infrastructure of the hardware connection, the 

25 prevailing network loading, the time of day and many 

26 other factors. The router then increments 44 the 

27 packet's value field 5 which is the packet's internal 

28 record of its own value by this calculated value. 
29 

30 The router then transmits 46 the packet along the 

31 hardware connection along which the packet is to be 

32 dispatched. Following transmittal the router checks 48 
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1 that the recipient machine has acknowledged successful 

2 transfer of the packet (assuming the transfer protocol 

3 supports this) . If the transfer is not successful, 

4 then this is handled under the existing transport 

5 protocol 50. If the transfer is successful the router 

6 increments 52 the recorded total value transmitted to 

7 this hardware connection by the value of the packet. 

8 The recorded total value transmitted is stored by the 

9 router. 
10 

11 For each router or hardware connection, the total value 

12 transmitted minus the total value received (e.g. in 

13 Network Credit Units) is the net profit (or loss) that 

14 must be reconciled with the owner of the machine at the 

15 other end of that hardware connection. This is used to 

16 determine the economic value of the accumulated 

17 transactions and forms the basis of the hard currency 

18 exchanges necessary to finance the activities and the 

19 provision of the infrastructure. 
20 

21 Physical network connections can be created and re- 

22 arranged relatively easily and network service 

23 providers can normally be changed at will. It is 

24 therefore anticipated that the kind of business system 

25 envisaged by the present invention will lead to a very 

26 efficient market constituted of very many providers of 

27 connections and routing bandwidth who serve, 

28 collectively, a very large number of content providers 

29 and information consumers. For example, if the 

30 financial arrangements were controlled in this manner, 

31 it might reasonably be envisaged that the 

32 infrastructure would evolve to support video on demand. 
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1 This would be based upon an enormous supply of 

2 material, effectively a distributed archive of all the 

3 material ever produced. It would satisfy the market by 

4 the laws of supply and demand. 
5 

6 One of the major problems associated with any data 

7 distribution, and particularly digital data, is that of 

8 unauthorized redistribution. Matters of privacy and 

9 security are also general problems in the context of 

10 the Internet. For the purposes of the description of 

11 the invention, it is necessary only to consider whether 

12 the use of PTP implies any changes as compared to the 

13 situation at present. The system of the invention does 

14 not require transfer of data in ways other than those 

15 presently possible, and the proposed protocol of the 

16 invention would not inhibit any of the security or 

17 encryption methods used to prevent such unauthorised 

18 redistribution. In fact, security and encryption would 

19 be expected to take place at the level of the data 

20 within the packet stream, rather than acting at the 

21 packet level itself. 
22 

23 One important feature of the system of the invention is 

24 that it allows consumers to choose exactly what they 

25 require without having to pay for unwanted accompanying 

26 material. For example, they can select one track 

27 without having to pay for a complete music CD, or they 

28 can decide not to view the remainder of a film if they 

29 dislike the opening portion. Also, the purchase price 

30 should be subject to very keen competition. These 

31 facts in themselves mean that there is less temptation 

32 to acquire material from illegal sources. Any legal 
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1 deterrents become more effective if individuals can buy 

2 selectively only what they actually require, and at a 

3 fair price. 
4 

5 In addition, as individuals are presented with, and 

6 begin to utilize, the much greater choice of available 

7 information, their interests will rapidly diversify and 

8 their requirements will diverge. This will have the 

9 effect of making it more difficult to cache data as it 

10 passes through the network and resell it multiple 

11 times. If content becomes sufficiently cheap, it will 

12 not be worth the investment in hardware to cache it. 

13 There will be less demand for any particular content, 

14 so that the logistics of illegal storage for reselling 

15 become more expensive and therefore less attractive. 

16 This is not to say that a legal business of caching and 

17 reselling popular information could not build up, still 

18 within this framework. This could, for example, be how 

19 what are now broadcast services continue to make money. 

20 Network capacity will need a large step-change before 

21 commonly required content can be served to all clients 

22 from a single source, a matter which is presently 

23 addressed by the use of network caches, proxy servers 

24 and mirror sites on the Web. Such issues are tied in 

25 with copyright and ownership of content. For example, 

26 it is not generally possible for an end-user to tell 

27 whether content comes from its original provider or 

28 from some legitimate or illegitimate cache. Once 

29 again, the implementation of the system of the 

30 invention would not impact upon these matters of 

31 copyright and ownership of content. 
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1 The system of the invention as described above can also 

2 function with the concept of the network computer, 

3 which for example means that a user might have the 

4 option of purchasing the use of a software application 

5 for some period rather than actually buying the 

6 application outright. Once again, they receive (and 

7 pay for) only what they actually require, and always 

8 get the most up to date version so that rapid 

9 obsolescence is not a concern. 
10 

11 One other important feature of the PTP concept is that 

12 it can be interfaced with a conventional network, 

13 operating under a different business model, provided 

14 charging rates and so forth are agreed for the 

15 interfaces. This means that network fragments can be 

16 created or converted to conform to the PTP model as and 

17 when suits the infrastructure owner, so that gradual 

18 conversion is possible and a massive "roll -out" program 

19 is unnecessary. 
20 

21 It is possible that, for effective operation, the 

22 system of the invention will require international 

23 financing deals and clearing arrangements, as well as 

24 software controlled real-time network configuration 

25 changes and real-time pricing structure changes. 

26 However, the system of the invention offers two 

27 significant advantages, as follows. Firstly, the 

28 ultimate client always has transparent data on what the 

29 service being received is actually costing, over any 

30 desired time interval. This is regardless of the 

31 choice of information source, network service or demand 

32 driven costing changes. Secondly, PTP represent a good 
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1 approximation to a perfectly competitive and efficient 

2 market, and one in which the costs and revenues are 

3 intimately related at all stages to the actual 

4 activities from which they result. These features 

5 should be expected to encourage serious investment into 

6 infrastructure development. 
7 

8 Particular details of a method of implementing PTP in a 

9 TCP/IP environment will now be described. In 

10 particular, for the value quantity to be directly 

11 accessible for processing by the routers, the value 

12 field must be contained in the IP Layer header. This 

13 is because the TCP Layer header is considered purely as 

14 data by the routers that implement IP protocols and, as 

15 such, it is to be transported without any reference to 

16 its contents. However, for the value field to be 

17 useful to individual client and server applications for 

18 the purpose of enumerating the intrinsic worth of the 

19 data being transported, it must be accessible to these 

20 applications. The applications operate at the 

21 Application Layer of the TCP/IP stack and this layer 

22 interfaces with the TCP Layer, with the IP Layer being 

23 effectively invisible to the application. The matter 

24 is further complicated by the existence of UDP (User 

25 Datagram Protocol) , which provides an alternative 

26 protocol at the Transport Layer (and there might be 

27 additional alternatives, which either currently exist 

28 or will be defined in the future). The invention 

29 proposes three solutions to this, as follows. 
30 

31 The first solution is to have separate value fields. 

32 According to this solution there are two distinct value 
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1 fields, one in the IP Layer, to accrue measurement of 

2 the economic worth of performing the data transport 

3 operation, and one in the Transport Layer, to enumerate 

4 the intrinsic worth of the data. Such a solution does 

5 not allow the unification of the methods covering the 

6 two contributions to the economic model, and so is not 

7 the preferred solution. 
8 

9 The second solution is direct communication between the 

10 application and the IP Layer. Such communication can 

11 be hazardous with respect to the structure and 

12 implementation of the TCP/IP protocol and is not 

13 generally considered to be a realistic solution. There 

14 is a useful exception in the case of an "information 

15 server", a system dedicated to serving information on 

16 behalf of a content provider and which is accessed by a 

17 client dedicated , to the task of receiving that 

18 information. A server in such a system can run 

19 customised application software, in which the direct 

20 access to the IP Layer is available as required. The 

21 client works solely with the incoming information, so 

22 that the resources consumed (and measured in accordance 

23 with PTP) on behalf of the client application are 

24 indistinguishable from the total resources consumed by 

25 the client machine. This is the maximum level of 

26 detail that could be measured if the PTP values were 

27 accessed directly from the IP Layer, since IP does not 

28 work with reference to specific ports or the individual 

29 applications which are notionally attached to them. 
30 

31 The third, most favoured solution is integration with 

32 the Transport Layer. The PTP value field is 
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1 incorporated in the IP Layer header. The Transport 

2 Layer protocol (TCP, UDP or other) is aware of the 

3 value field and can convey the information to and from 

4 the Application Layer as required, even though this 

5 information is not written in the Transport Layer 

6 header and thus not considered to be conveyed at the 

7 Transport Layer level. The act of reading and writing 

8 the value field would still be expected to be the 

9 preserve of the of the IP Layer implementation 

10 software. This structuring appears to be analogous to 

11 the way in which applications can have access to IP 

12 addresses, although these are actually written in to, 

13 and read back from, the IP headers. 
14 

15 Practical details in implementing the router 

16 functionality required by the PTP system will now be 

17 described. Incrementing the value field does not 

18 impose an unacceptable processing overhead on the 

19 router. There is a precedent for this kind of 

20 processing in the way that the IP standard defines and 

21 utilises a time-to-live (TTL) value in the IP header. 

22 This is subject to a decrement each time a router hop 

23 occurs. This capability can be extended to include a 

24 simple addition to the value field at the same point in 

25 the processing. This operation is likely to be an 

26 integer addition or binary add function on a specific 

27 bit field in the packet header, a relatively 

28 straightforward procedure. At the same time 

29 developments in hardware technology will go some way to 

30 compensating for the increased burden placed upon the 

31 network infrastructure by the implementation of PTP. 

32 Dedicated hardware may be used to support the value 
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1 field modification. Since there is an intimate 

2 relationship between the physical network connections 

3 and the particular value of the increment to be 

4 applied, an appropriate piece of equipment can be 

5 placed "in line" on each physical network connection, 

6 to perform the task. Such a unit can respond to its 

7 own communications protocol (something akin to the way 

8 routers work with ICMP (Internet Control Message 

9 Protocol) , ARP (Address Resolution Protocol) and RARP 

10 (Reverse Address Resolution Protocol)) to receive 

11 updates to the algorithm for the value to be added to 

12 passing packets and also to return accumulated totals 

13 at appropriate times. Otherwise it operates as a 

14 standalone piece of network infrastructure, logging and 

15 incrementing the values of passing packets. Such a 

16 configuration alleviates the need for routers to 

17 allocate the accumulating values to particular network 

18 connections or IP addresses in real time, as they 

19 process the packets. 
20 

21 In addition, it is also possible that, rather than each 

22 and every router performing its own increment to the 

23 value field, a more "coarse grained" implementation of 

24 the PTP model could be applied. This would occur if 

25 the provider of a particular piece of infrastructure 

26 were willing to consider that piece of infrastructure 

27 (e.g. an optical fibre "backbone") as a zone and 

28 therefore apply a more straightforward tariff for 

29 transportation across the zone. This would mean that 

30 the logging and increasing of the value fields of 

31 packets transported across the zone would only need to 

32 take place at the zone boundaries. This scheme is 
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1 effectively equivalent to considering the flow chart of 

2 Fig. 3 to apply to a network zone rather than an 

3 individual router. 
4 

5 These and other modifications and improvements can be 

6 incorporated without departing from the scope of the 

7 invention. 
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1 CLAIMS 

2 

3 1. A method of electronic payment for data 

4 transferred across a computer network containing at 

5 least one client, at least one server and at least one 

6 router which forwards data, the method comprising the 

7 steps of: 

8 sending an electronic data request from a client 

9 to a server via one or more routers; and 

10 sending electronic data from said server to said 

11 client via one or more routers in response to said 

12 electronic data request, said electronic data having 

13 associated with it a data field containing a value 

14 which represents the commercial value of the data 

15 contained within the electronic data. 
16 

17 2. A method according to Claim 1 in which the 

18 electronic data is transmitted in the form of packets. 
19 

20 3. A method according to Claim 2, wherein each of 

21 said one or more routers receives an incoming data 

22 packet, reads the value in the data field associated 

23 with the incoming data packet, calculates a new value 

24 based on the read value and the cost of forwarding the 

25 data packet, and forwards the data packet with the new 

26 value in the associated data field. 
27 

28 4. A method according to Claim 3, wherein each of 

29 said one or more routers checks whether the value in 

30 the data field associated with the incoming data packet 

31 falls within predefined parameters and rejects the 
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1 packet if the value falls outside the predefined 

2 parameters . 
3 

4 5. A method according to any preceding Claim, wherein 

5 the electronic data request has associated with it a 

6 data field containing a value which represents the 

7 commercial value of the data contained within the 

8 electronic data request. 
9 

10 6. A method according to any preceding Claim, wherein 

11 total accumulated values for transactions between 

12 routers or between routers and servers/clients are 

13 recorded. 
14 

15 7. A method according to Claim 6 # wherein clearance 

16 payments are made between the operators and/or users of 

17 the routers and servers/clients, the clearance payments 

18 corresponding to the total accumulated values. 
19 

20 8. A system of electronic payment for data based on a 

21 hardware infrastructure of linked routers, data 

22 providers and data users, comprising: 

23 at least one client; 

24 at least one server for providing electronic data 

25 in the form of data packets in response to a request 

26 from a client and having its operation governed by a 

27 server protocol which causes each data packet sent by 

28 the server to have associated with it a data field 

29 representing the value of the data contained within the 

30 packet; 

31 at least one router linked by a hardware 

32 infrastructure to said server and said client and 
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1 having its operation governed by a routing table and a 

2 router protocol; 

3 whereby the router protocol causes each router to 

4 add commercial value to the packet by forwarding it in 

5 accordance with the routing table and to update the 

6 value contained in the data field within the packet to 

7 reflect this added commercial value. 
8 

9 9. A system according to Claim 8, wherein the router 

10 protocol also includes procedures for rejecting 

11 individual packets in accordance with pre-defined 

12 parameters related to the value of each packet on 

13 receipt . 
14 

15 10. A method of electronic payment for data 

16 transferred across a computer network containing at 

17 least one client, at least one server and at least one 

18 part of the network which forwards data, the method 

19 comprising the steps of: 

20 sending an electronic data request from a client 

21 to a server via the part of the network; and 

22 sending electronic data from said server to said 

23 client via the part of the network in response to said 

24 electronic data request, said electronic data having 

25 associated with it a data field containing a value 

26 which represents the commercial value of the data 

27 contained within the electronic data. 
28 

29 11. A method according to Claim 10 in which the 

30 electronic data is transmitted in the form of packets. 
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1 12. A method according to Claim 11, wherein the part 

2 of the network has an associated data processor which 

3 reads the value in the data field associated with an 

4 incoming data packet received by the part of the 

5 network, calculates a new value based on the read value 

6 and the cost of forwarding the data packet, and 

7 forwards the data packet with the new value in the 

8 associated data field. 
9 

10 13. A method according to Claim 12, wherein the data 

11 processor checks whether the value in the data field 

12 associated with the incoming data packet falls within 

13 predefined parameters and rejects the packet if the 

14 value falls outside the predefined parameters. 
15 

16 14 . A method of electronic payment for requested data 

17 transferred across a computer network containing at 

18 least one client, at least one server and at least one 

19 router which forwards data, in which the requested data 

20 is sent from said server to said client in the form of 

21 a packet, 

22 wherein said packet comprises a packet header and 

23 packet data, 

24 the packet data containing the requested data, and 

25 the packet header containing one or more address 

26 fields containing address information relating to the 

27 client and/or server and a data field containing a 

28 value which represents the commercial value of the 

29 requested data contained within the packet data. 
30 

31 15. A method according to Claim 14, wherein the data 

32 is sent via the router which reads the value in the 
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1 data field of the incoming data packet received by the 

2 router, calculates a new value based on the read value 

3 and the cost of forwarding the data packet, writes the 

4 new value to the data field, and forwards the data 

5 packet with the new value in the data field. 



WO 00V79494 



PCT/GB00/02413 



1/2 




Fig. 2 



SUBSTITUTE SHEET (RULE 2Q 



WO 00/79494 



PCT/GB00/02413 



2/2 



30, 



RECEIVE PACKET 



32^ 



CHECK UNDER EXISTING 
TRANSPORT PROTOCOL 



36, 



40. 



VALUE BELOW LIMIT? 



42. 



INCREMENT TOTAL 
RECEIVED VALUE 
RECORD 



44> 



CALCULATE ADDED 
VALUE 



INCREMENT PACKET 
VALUE RECORD 



46. 



48, 



TRANSMIT PACKET 



52^ 



IS TRANSFER 
SUCCESSFUL? 



INCREMENT TOTAL 
TRANSMITTED VALUE 
RECORD 



34, 



REJECT PACKET 



38, 



REJECT PACKET 



50, 



EXISTING 

TRANSPORT 

PROTOCOL 



Fig. 3 



J5UBSTTTUTE SHEET (RULE 26) 



INTERNATIONAL SEARCH REPORT 



InU Jonal Application No 

PCT/SB 00/02413 



A. CLASSIFICATION OF SUBJECT HATTER 

IPC 7 G07F17/16 G07F7/10 H04L12/14 



According to International Patent Classification (IPC) or to both national classification and IPC 



& FIELDS SEARCHED 



Mntmum documentation searched (classification system followed by classification symbols) 

IPC 7 G07F H04L H04B G06F H04H 



Documentation searched other than minimum documentation to the extent that such documents am included in the fields searched 



Bectroric data base consulted during the international search (name of data base and. where practical, search terms used) 

EPO-Internal 



a DOCUMENTS CONSIDERED TO BE RELEVANT 



Category* 


Citation of document with inolcation, where appropriate, of the relevant passages 


Relevant to daJm No. 


X 


EP 0 788 080 A (CANON KK) 


1,3,4,10 




6 August 1997 (1997-08-06) 




column 5, line 21 - line 24 




Y 


column 5, line 39 - line 57 


2 




column 6, line 6 - line 20 




A 


column 10, line 17 - line 21 


6 


A 


EP 0 537 756 A (FUJITSU LTD) 


1,8,10, 




21 April 1993 (1993-04-21) 


14 




abstract; figure 1 






column 4, line 9 - line 47 






column 7, line 9 -column 8 f line 43 




A 


US 5 754 787 A (DEDRICK RICK) 


1,8,10, 




19 Hay 1998 (1998-05-19) 


14 




claim 1 






-/- 





Further documents are listed in the continuation of box C. 



Patent family members are listed in annex. 



° Special categories of cited documents : 

"A" document defining the general state of the art which is not 

considered to be of particular relevance 
*£ a earlier document but published on or after the international 

filing date 

"L" document which may throw doubts on priority daim(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

"O" document referring to an oral disclosure, use, exhibition or 
other means 

*P" document published prior to the international filing date but 
later than the priority date claimed 



T later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

"X" document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
sivolve an inventive step when the document is taken alone 

*Y" document of particular relevance; the claimed invention 
cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person stated 
in the art 

'&" document member of the same patent family 



Date of the actual completion of the international search 

24 October 2000 



Date of mailing of the international search report 

07/11/2000 



Name and mailing address of the ISA 

European Patent Office, P.B. 581 8 Patentlaan 2 
NL-2280HVRyswi* 
Tel. (431-70) 340-2040. Tx. 31 651 epo nl. 
Fax: (+31-70) 340-3016 



Authorized officer 



Lindholm, A-M 



Form PCT/1SA/210 (Mcond shaet) (Jury 1992) 



page 1 of 2 



INTERNATIONAL SEARCH REPORT 



tntt lonai Application No 

PCT/GB 00/02413 



C(Oontktuatlon) DOCUMENTS CONSIDERED TO BE RELEVANT 



Category ° Citation of document with indcati on, where appropriate, of the relevant passages 



Relevant to claim No. 



US 5 910 987 A (GINTER KARL L ET AL) 
8 June 1999 (1999-06-08) 
column 96, line 9 - line 55 



Forni PCT/tSA/210 (oontinuztian at second sheet) (Ji4y 1 992) 



page 2 of 



2 



INTERNATIONAL SEARCH REPORT 

Ciifui mfltlon on pstmt family members 



bit Jona) A p pfl caU uH No 

PCT/GB 00/02413 



Patent document 
cited in search report 



Pubtcation 
date 



Patent family 
members) 



PubScation 
date 



EP 0788080 



06-08-1997 



JP 
JP 



9212554 A 
9212252 A 



15-08-1997 
15-08-1997 



EP 0537756 A 21-04-1993 JP 5122145 A 18-05-1993 

JP 2811379 B 15-10-1998 

JP 5122173 A 18-05-1993 

DE 69231118 D 06-07-2000 

US 5884140 A 16-03-1999 



US 5754787 A 19-05-1998 NONE 



US 5910987 


A 


08-06-1999 


AU 


711733 B 


21-10-1999 








AU 


6326696 A 


18-09-1996 








CA 


2212574 A 


06-09-1996 








CN 


1183841 A 


03-06-1998 








EP 


0861461 A 


02-09-1998 








JP 


10512074 T 


17-11-1998 








UO 


9627155 A 


06-09-1996 








US 


5949876 A 


07-09-1999 








US 


5915019 A 


22-06-1999 








US 


5917912 A 


29-06-1999 








US 


5982891 A 


09-11-1999 



Form PCT7ISA/21 0 (patent bnnty annex) (Jtfy 1 992) 



